The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In one approach for using user-defined indexes to evaluate queries, a conventional user-defined index provides a cost function which, when invoked by a query optimizer of a database server, returns a cost of using the index to evaluate a portion of a query. Based on the returned cost, the query optimizer then makes a decision whether to use the user-defined index to evaluate the query portion in the execution plan that the query optimizer generates for the query.
This approach, however, suffers from several disadvantages. One disadvantage of this approach is that the cost returned by the cost function of the conventional user-defined index indicates the cost of using the entire index. This is because a conventional user-defined index can only evaluate a query predicate that includes a user-defined operator that is supported by the index. Thus, the cost returned by the cost function of the user-defined index is largely invariable because it is only associated with the evaluation of the same user-defined operator. In turn, this causes the query optimizer to generate sub-optimal execution plans for queries that include predicates with that user-defined operator.
Another disadvantage of this approach is that it results in the query optimizer deciding whether to use a user-defined index on an all-or-nothing basis. Since a conventional user-defined index can be used to evaluate only a specific user-defined operator and since the cost returned by the cost function of the user-defined index is largely invariable, the query optimizer of a database server is forced into making a choice of whether to use or not to use the user-defined index in the execution plan that the query optimizer generates for a query. In turn, this limits the options that might be otherwise available to the query optimizer for generating an execution plan that can be used by a database server to evaluate the query more efficiently and with less processing resources such as memory, CPU time, and I/O cycles.